ADAS/AD开发16

前言

AUTOSAR就不多介绍了，Automotive Open System Architecture，汽车开放系统架构。同时，AUTOSAR也指一个汽车联盟，发起于欧洲汽车行业，用于推广AUTOSAR架构。

这个架构可以实现汽车电子的软硬件分离。用了AUTOSAR之后，你开发汽车软件就可以像在PC或者手机上开发软件一样，只开发你的软件（现在的PC软件或者手机APP开发，有几个软件开发人员关注过你的电脑或手机的硬件BOM列表吗？用的什么牌子的内存，什么硬盘，什么驱动，什么CPU。你压根也不关心吧？）。AUTOSAR架构，也想实现这种效果。

降低ECU软件开发的复杂度，提高软件可重用性。使开发者避免因为采用私有的协议和解决方案导致日益增长的开发成本。

总的来讲，AUTOSAR架构的核心思想就是“统一标准、分散实现、集中配置”（来自哈工大的一篇硕士论文）。统一标准和集中配置，都是加强OEM的地位。因此AUTOSAR是一个对主机厂非常有利的开发架构，能够稀释一些强势供应商的影响力和技术掣肘。

由于AUTOSAR只是一个软件框架，不具备实操意义（务虚）。因此Vector就开发了一系列可重用软件包，以及对这些软件包进行配置的开发工具。说白了，就是一但你用了人家的这套解决方案，软件基本就不用再开发了，人家都按模块把各种基础软件都开发好了，你自己只需要搞几个人培训下，会用人家给你提供的工具，直接在人家的软件库里按需要配置、集成软件就行。当然，也有不少其他公司的AUTOSAR解决方案可以使用。

大家也知道工具对一项工作的基础性塑造作用。举个例子，一个人谈起iOS开发时，脑子里是有画面的，就像放电影那样。那种画面，实质上是一个人坐在电脑前，对XCode这个IDE环境的使用。当你聊起故事板时，你说的其实是XCode里的创建出的故事板的那个工具界面，以及对那一系列界面的操作。同样的，当一个人讨论到CAN诊断时，脑子里的画面很可能是使用CANoe的场景，说到CAN消息，很可能是打开dbc查看器展示出来的窗口界面。如果其他人没有玩过这个工具，就很难理解他在讲什么。

基于Vector的AUTOSAR解决方案的开发流程和所用工具是这样的：

图 1 Vector的AUTOSAR解决方案

由于AUTOSAR能实现软硬件分离，可以认为，AUTOSAR架构中的系统开发不仅仅是ECU控制器层面的系统了，而是整车系统。

需要指出，以上的开发工具，例如PREEVision、DaVinci等工具的软件开发，都是基于MBD（Model Based Design）开发的。即，都是可视化编程语言。

个人认为，可能传统的汽车行业，从来也不把自己定位为软件公司，因此在遇到代码开发时，倾向于采用降低“门槛”的方式，基于模型的开发方式特别流行。

不过，事情总在变化。现在很多OEM已经喊出了软件改造汽车的口号。除去特斯拉这种一开始就定位为硅谷科技公司的异类，包括通用等美国车企也都非常激进的进行"软件化"改造，慢慢在脱离制造的身份。供应商里，德尔福改名安波福，奥托立夫成立维宁尔公司等，都是激进的将自己直接从汽车提供商变成了科技公司，也很说明问题。

以下通过对工具的介绍，来详细阐述Vector的AUTOSAR解决方案。

正文：

PREEvision - 系统架构设计及优化工具

Cover的工作包有：

需求开发、管理；

功能逻辑设计、功能分配；

网络架构；

部件架构；

电气系统和线束设计；

拓扑结构设计。

PREEvision按照分层设计思想展开（如下图），主要包括需求层、功能逻辑层、硬件系统层、线束层、拓扑层等层面的设计。

图2 PREEvision分层开发模式

1.需求层（Requirements Layer）：

该层需要导入需求开发的输出物：需求说明书，作为工程设计的指导文件。当然这些需求说明书的存在形式不一定是Word文档，也可以存在于DOORS、Polarion等需求管理工具中。该层主要用来描述电子电气系统要实现的功能需求和非功能需求，是电子电器架构设计的起点。

在PREEvision中，需求层一般由三部分组成：Requirement、Customer Feature、FFN。

Requirements 的结构一般与具体开发流程相关。

Customer Feature的结构类似Requirement。用于描述客户所关心的车辆配置信息。该模块一般用作市场信息的交互。

FFN，Feature Function Network 特性功能网络。特性功能网络主要描述一个系统功能的内部情况。包括因果链及在系统内相互关系。“因果链”是系统设备的分解，由“请求者”、“功能体”、“执行者”三部分组成。一般来说，“请求者”需要通过“功能体”达到“执行者”执行某一命令的目的。“功能体”是执行者某种行为的描述，“执行者”是功能体的任务承担者。“因果链”可以用于识别各个系统同时运行时的冲突和干涉。

2. 功能逻辑层：

该层用于描述系统的逻辑功能关系，即系统功能的模块框架以及各模块之间的接口关系。主要包括两个层面的内容：系统逻辑架构层和软件架构层。前者关注系统功能实现的所有逻辑关系；后者关注系统实现过程中的软件相关的逻辑关系。内容包括逻辑传感器、功能块、逻辑执行器等功能模块，以及各功能模块之间的信息交互接口（Port）。当各模块之间的端口通过信息交互接口连接后，相应模块就能进行数据和控制信息的交换。在功能逻辑架构中，开发人员可以方便的查看各个功能模块之间的逻辑关系。

a. 逻辑架构设计。逻辑架构遵从AUTOSAR标准的定义，包括逻辑传感器、功能块和逻辑执行器。这些功能模块一层次结构的方式组织并存储在组合模块中。功能模块之间通过信息交互进行连接。当两个功能模块的端口通过信息交互接口连接后，相应模块就能进行数据和控制信息的交换。在功能网络里，用户可以看到各功能模块之间的逻辑关系。

b. 开发功能类型库。在“逻辑网络”中，各模块端口上的接口信息都需要事先在功能类型库中定义。功能类型库描述了所分配端口需要或提供的信息。这里的接口可近似看成技术通讯协议。在“逻辑网络”建模以及对整个网络信号进行路由规划过程中，接口定义一致的端口之间的兼容性可以在PREEvision所反映。PREEvision提供针对Matlab/Simulink模型和ETAS/ASCET文件的功能模块导入功能。

3. 硬件架构层（Hardware Architecture Layer）：

该层主要包括网络层（Network Layer）、部件层（Components Layer）和线路原理层（Schematic/Circuit Layer）。网络层主要描述各个部件之间的逻辑链接方式，如总线系统、传统连接、电源供应和地线连接等（还会在线路原理层进行进一步细化）；部件层描述每个部件内部构成及其对外接口的详细信息；线路原理层描述网络层中逻辑连接的具体实现情况，如：具体导线、线缆连接方式、保险继电器盒内部结构等。

4. 线束层（Wiring Harness Layer）：

所谓线束层，是指功能逻辑层和硬件系统层（具体是线束原理层）的连接关系的物理实现。该层可将线路原理层的连接关系在电线和电缆两方面进一步细化，将线束特定的属性添加到模型中。在改层中每段电线及相应的接插件都具有物理属性（单位长度重量、成本、过流能力等）。线束元素将来可以在拓扑结构中形成具体的电线和电缆布局。

5. 拓扑层（Topology）：

该层描述了电子电气系统的实际布置情况。设计人员需要根据实际情况，确定各个部件以及线束的最终安装位置，需要设定不同安装位置之间的“线路段”的具体长度。之后便可以得出电子电气系统中的整个线束的统计长度。

/////////////// 2019.01.29 更新 //////////////////

DaVinci Developer - SWC开发工具（开发Feature）

AUTOSAR中的SWC其实就相当于应用程序（APP），对应传统开发中用MATLAB/Simulink开发的feature模型（ACC/AEB/FCW/LDW/LKA等）。是应用层软件的开发工具，也是一种基于模型的开发方式（MBD - model based design）。既可以使用图形用户界面开发功能逻辑，也可以定义应用程序接口，当然也可以用于配置RTE源代码。具体功能如下：

导入AUTOSAR的ECU交换文档(Extract of ECU Description File)

图形化定义软件组件(SWC)

定义端口(Ports)和数据类型(Data Elements)

将运行实体(Runnables)映射到操作系统任务(Task)中

导入/导出AUTOSAR的arxml文件

从网络数据库中导入信号

针对ECU配置的一致性校验

与Matlab/Simulink无缝集成

MICROSAR - 根据AUTOSAR标准开发的产品级的、可重用的、嵌入式软件组件库

常见的嵌入式组件包括：

RTE 运行时环境组件（中间件？）

MCAL 微控制器外围驱动组件

OS 操作系统组件

COM 通信组件

IO 输入输出组件

SYS 系统相关的基本组件

DIAG 诊断组件

等等；

下图是所有的软件组件列表：

因为是嵌入式软件，其支持的硬件也必须足够广泛，才能称之为“软件组件库”。目前MICROSAR支持绝大部分市场上的车用芯片（列表忘记在哪看到了，就不贴出来了）。配置时，可以选择对应的BSW和芯片类型。

这个库就是人家vector工具提供方，将ECU能用到的软件组件都开发好了，你花钱买，然后用人家的配置工具按需要集成下所需要的一系列软件组件，generate出嵌入式代码就行了。工具提供方会实时跟踪行业发展需求，有新基础软件需求了，就赶紧开发出对应模块，并更新到配置工具里，让客户花钱买，直接用。比如，现在流行以太网通信了，就赶紧更新几个以太网通信模块；或者有网络安全要求了，就开发出几个网络安全相关的软件模块，让OEM买。

DaVinci Configurator Pro - 调用MICROSAR的资源配置BSW工具

DaVinci Configurator Pro是符合AUTOSAR标准的软件配置工具，专门用于配置并生成ECU中的Basic Software(BSW)。它能保证在配置各底层软件模块的过程中，各配置参数的一致性。如果出现配置数据错误或缺失，DaVinci Configurator Pro能及早发现并提出警告。

你可以选择合适基础服务软件模块，经过配置，选择合适的芯片（MCU），最后生成嵌入式软件的配置工具。这个工具的优点是：

使用图形化的配置简化了各参数间复杂的内部关系

支持在同一系统中并行配置不同版本的BSW(如2.1和3.0)

基于AUTOSAR规范的验证过程

依然使用GENy来配置通信相关模块(为CANbedded用户带来方便)

针对BSW配置的一致性校验

总结：

基于Vector的AUTOSAR其实不是一个从无到有、从0到1的开发工具。它已经帮你造好了轮子。各种BSW应有尽有，你需要做的就是在需求层面（PREEvision）开发出自己的东西，然年后用DaVinci Developer搭好功能逻辑（或者从原有的Simulink的功能模型导入到DaVinci Developer中），生成源代码。然后用DaVinci Configurator Pro调用MICROSAR 这个现成的软件库资源（每个软件包都是要花钱买的），配置出（集成）基础软件。都省得敲代码开发了...全是用工具配置并生成的自动代码...